NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/hardware-part1/6281

Text File | 1996-08-05 | 3.8 KB | 76 lines

Newsgroups: comp.sys.amiga.hardware
Path: admaix.sunydutchess.edu!ub!dsinc!scala!news
From: [e-mail] (Dave Haynie)
Subject: Re: Amiga vs. PC
Sender: [e-mail] (Usenet administrator)
Message-ID: <[e-mail]>
Date: Tue, 5 Mar 1996 17:27:06 GMT
Reply-To: [e-mail] (Dave Haynie)
References: <4glavu$[e-mail]> <4glb5c$[e-mail]> <[e-mail]> <Joaquin_Menchaca-0103962126590001@17.127.19.156> <[e-mail]> <Pine.BSD/[e-mail]>
Nntp-Posting-Host: gator
Organization: Scala Computer Television, US Research Center

In <Pine.BSD/[e-mail]>, ":=Rob=:" <[e-mail]> writes:

>> The 68000 was a 16 bit microprocessor trying its best to emulate a
>> 32 bit processor.  The instructions were all 32 bit, but internally
>> it was processed as two 16 bit halves.  The 68020 was the first
>> 32 bit core.

>I dont think so.  If you want to get that technical, then the
>instructions were not 32-bit either.  The 68000-series processors have
>16-bit instructions, not 32.  The data is what is fully 32-bit.

When you refer to "32-bit" or "16-bit" instruction in discussing CPUs,
you're referring to the data size of the operation, not the physical
size of the instruction. The 680x0 architecture has instructions that
vary in length, 16-bits, 32-bits, 48-bits, etc. The 68000 is a 32-bit
processor because it has 32-bit wide registers, operates on 32-bit
data, etc. It is also a 16-bit processor because internally, it's
doing mush of this with 16-bit ALUs and datapaths.

>Instruction size is irrelevent,

There you go. The instruction size has no bearing on the "32-bit-ness"
of the CPU. In fact, there's this CPU from InMOS, the Transputer,
which had its 15 minutes of fame some years back. It's a 32-bit
machine, but as a stack machine, you don't typically even have to
address registers. So it has quite a few 32-bit instructions which are
8-bits long.

>and in fact it would increase performance the smaller they are.

That's not necessarily true. While you can fetch more instructions
per bus cycle when they're small, it's more complicated to decode them
if they vary in size, or if they're hashed (eg, their function can
only be determined via lookup table, not by decoding various
bitfields). That is, at least, if the processor is classically
designed such that the fetch unit and CPU pipeline are tightly
coupled.

A few recent architectures, such as AT&T's Hobbit and one spin of
Advanced RISC Machines' ARM architecture do achieve a performance
increase this way. They have a more loosely coupled connection between
CPU core and the external bus, using the cache as an intermediate
stage (as many RISC and RISC-wannabe architecture have done in recent
times). The bus fetch unit grabs compressed instructions from memory,
decodes them into the machine's natural format, and stuffs them in the
cache. Since the bus fetch time is usually going to give you at least
a clock's worth of pipeline stall (at least when it can't be
overlapped with something else), the compressed instruction overhead
can usually be hidden. But this is a fairly recent thing, and not used
on any 680x0 architecture. Something similar is being done in modern
80x86 processors, where x86 instructions are decoded to one or more
internal, RISC-like instructions.

>Do you think that the Pentium has 64-bit instructions?

It doesn't, unless you could floating point (which you don't).

Dave Haynie          | ex-Commodore Engineering |   for DiskSalv 3 &
Sr. Systems Engineer |  Hardwired Media Company | "The Deathbed Vigil"
Scala Inc., US R&D   |    Ki No Kawa Aikido     |     [e-mail]

         "Feeling ... Pretty ... Psyched" -R.E.M.